Registries
A registry is the authoritative list of a class of things, with an identifier for each. Client registries hold people, facility registries hold places, health worker registries hold providers, product registries hold commodities.
They are the foundation of exchange. Two systems can share a perfectly valid
FHIR Observation and it is worthless if they disagree about which patient it
belongs to, or which facility produced it.
Countries that build the interoperability layer before the registries usually end up rebuilding it. This is the single most reliable prediction in this field.
The types
| Registry | Holds | Standards | Typical owner |
|---|---|---|---|
| Client registry / MPI | Patients and clients | FHIR Patient, IHE PIX/PDQ | Ministry of health or national ID authority |
| Facility registry | Health facilities and service delivery points | FHIR Location, Organization | Ministry of health |
| Health worker registry | Providers, their roles and qualifications | FHIR Practitioner, PractitionerRole | Ministry, or professional councils |
| Organisation registry | Legal entities — hospital groups, NGOs, insurers | FHIR Organization | Ministry or business registry |
| Product catalogue | Medicines, vaccines, commodities | GS1, national drug codes | Regulator or procurement agency |
| Terminology registry | Code systems, value sets, maps | FHIR CodeSystem, ValueSet | See terminology services |
| Device registry | Equipment and its location | FHIR Device | Ministry / biomedical engineering |
| Immunisation registry | Doses administered per person | FHIR Immunization | Immunisation programme |
| Disease registries | Cancer, TB, HIV, rare disease cohorts | Programme-specific | Disease programme |
| Civil registration | Births and deaths | National standards | Civil registration authority |
The first three are the OpenHIE core, and they are enough to start.
Registry versus repository
A distinction worth enforcing:
- A registry holds identity and a small set of attributes needed to identify and locate. It answers who and where.
- A repository holds the substantive data. It answers what happened.
Client registries hold demographics and identifiers, not diagnoses. Facility registries hold codes, names, locations and service types, not monthly reporting figures. Registries that accumulate operational data become slow, sensitive and contested, and lose the property that made them useful — being small, stable and universally trusted.
Identifier design
The decisions here outlive everything else in the architecture. Make them deliberately and record them in an ADR.
Namespacing
An identifier without a namespace is ambiguous. FHIR expresses this as a
system URI plus a value:
"identifier": [
{ "system": "http://moh.gov.example/nid", "value": "123456789" },
{ "system": "http://hospitalA.example/mrn", "value": "A-0042" }
]
Every issuing authority needs a registered, permanent namespace URI. Publish the list; do not let each project invent one.
Local plus shared
Point-of-service systems must be able to hold both their local identifier and the shared one. A system that supports only one identifier per patient cannot participate in a federated ecosystem — this belongs in procurement requirements, not in an integration discovery phase.
Check digits and format
A check digit catches the majority of transcription errors at the point of entry, which is far cheaper than reconciling them later. Define the format, publish the validation algorithm, and enforce it in every client.
The absent identifier
Design for it explicitly, because it is the common case:
- Newborns, before any identifier is issued
- Unconscious or unidentified patients in emergencies
- Undocumented and displaced populations
- Systems not yet integrated with the national ID
The usual answer is a temporary identifier issued by the registry, with a defined process for later merging into the permanent one. If you do not design this, clerks will invent it — typically by entering fake national ID numbers, which corrupts the registry permanently.
National ID and health identifiers
Using the national ID as the health identifier is convenient and carries costs:
| Reuse national ID | Separate health identifier | |
|---|---|---|
| Matching quality | Higher, if coverage is good | Depends on your own registry |
| Coverage | Excludes anyone without one — often the most vulnerable | Can cover everyone |
| Linkage risk | Health data becomes trivially linkable to tax, police, welfare | Linkage requires deliberate mapping |
| Governance | Depends on another agency's policy and outages | Under health governance |
A common middle path: a distinct health identifier, cross-referenced to the national ID where one exists. See digital public infrastructure for how this interacts with foundational identity systems.
Cross-cutting requirements
Every registry needs these, and they are usually under-specified:
- A canonical read API with pagination, search and change notification
- A change feed — downstream systems need to learn about new and updated entries without polling everything
- Versioning and effective dates — a facility that closed in 2024 must still resolve for data recorded in 2023
- Merge and unmerge — with full history, because merges are sometimes wrong
- Stewardship — a named team that adjudicates, not an automated process alone
- Audit — who changed what, when, and on what evidence
- An offline story — a downloadable snapshot for systems that cannot query live. See offline-first.
- Data quality monitoring — duplicate rate, completeness, staleness, tracked over time
That last point is the one that separates a maintained registry from an abandoned one. Publish the numbers.
Sequencing
- Facility registry first. It is the least politically contentious, the smallest dataset, and almost everything else depends on it.
- Health worker registry second, if professional council data exists to seed it.
- Client registry when individual-level exchange is actually needed — not before, because it is expensive to run and the matching quality depends on having real data flowing through it.
- Product catalogue when supply chain integration begins.
- Terminology throughout — it is needed from the first coded field.
Open-source options
| Project | Registry type | Notes |
|---|---|---|
| OpenCR | Client registry | OpenHIE community client registry, FHIR-based |
| SanteMPI / SanteDB | Client registry | Master patient index and health data platform |
| OpenEMPI | Client registry | Long-established MPI; check current activity |
| GOFR / FHIR-based facility registries | Facility | Global Open Facility Registry work in the OpenHIE community |
| DHIS2 organisation unit hierarchy | Facility (de facto) | Many countries' facility list lives here in practice |
| HAPI FHIR | Any | A conformant FHIR server can back a registry with appropriate profiles |
All Tier 2. Verify current maintenance status before selecting — see the platform directory.
References
- OpenHIE architecture — https://ohie.org/
- FHIR
Patient— https://hl7.org/fhir/patient.html - FHIR
LocationandOrganization— https://hl7.org/fhir/location.html - FHIR
Practitioner— https://hl7.org/fhir/practitioner.html - IHE PIX/PDQ profiles — https://www.ihe.net/